可靠指不错、不丢、不乱。可靠数据传输的框架如下图所示，为上层实体提供的服务抽象是：数据可以通过一条可靠的信道进行传输（如图 (a) 所示）；实现这种服务抽象是可靠数据传输协议（reliable data transfer protocol, rdt）的责任，由于可靠数据传输协议的下层协议也许是不可靠的（如图 (b) 所示），因此这是一项困难的任务。

下面我们渐进地设计可靠数据传输协议的发送方和接收方，且仅考虑单向数据传输（unidirectional data transfer）的情况，即数据传输是从发送端到接收端的，但控制信息是双向流动的。

首先考虑最简单的情况，即底层信道是完全可靠的，我们称该协议为rdt 1.0，该协议本身是简单的，发送方和接收方的有限状态机（Finite-State Machine, FSM）如下图所示：

发送方和接收方的 FSM 都只有一个状态，rdt 的发送端只通过 rdt_send(data) 事件接收来自较高层的数据，产生一个包含该数据的分组（经由 make_pkt(data) 动作），并将分组发送到信道中；在接收端，rdt 通过 rdt_rcv(packet) 事件从底层信道接收一个分组，从分组中取出数据（经由 extract(packet, data) 动作），并将数据上传给较高层（通过 deliver_data(data) 动作）。

实际上，rdt_send(data) 事件是由较高层应用的过程调用产生，rdt_rcv(packet) 事件是由较低层协议的过程调用产生的。

假设底层信道仅可能产生位错误，即可能将某比特由 0 翻转为 1，由 1 翻转为 0，仍然假定所有发送的分组（虽然有些比特可能受损）将按其发送的顺序被接收。

考虑一下你自己是怎样通过电话口述一条长消息的：报文接收者在听到、理解并记下每句话后可能会说“OK”；听到一句含糊不清的话时，他可能会说“请重复一遍”。这种方法使用了肯定确认与否请确认，这种控制报文使得接收方可以让发送方知道哪些内容被正确接收，哪些内容接收有误并需要重复。 在计算机网络中，基于这种重传机制的 rdt 协议称为自动重传请求（Automatic Repeat Request, ARQ）协议，它需要三种协议功能来处理存在位错误的情况：

下图说明了 rdt 2.0 的 FSM，该数据传输协议采用了差错检测、肯定确认与否定确认：

rdt 2.0 的发送端有两个状态:

rdt 2.0 的接收端的 FSM 仍然只有一个状态，当分组到达时，接收方要么回答一个 ACK，要么回答一个 NAK，这取决于收到的分组是否受损。

注意到：当发送方处于等待 ACK 或 NAK 的状态时，它不能从上层获得更多的数据，仅当接收到 ACK 并离开该状态时才能再次接收上层的数据，因此，rdt 2.0 这样的协议被称为停等（stop-and-wait）协议。

rdt 2.0 存在一个致命的缺陷，即没有考虑 ACK / NAK 分组受损的可能性！解决方法： （1） 可以为 ACK / NAK 增加校验和，检错并纠错，难度较高，且伴随着较高的代价； （2） 当发送方收到含糊不清的 ACK 或 NAK 分组时，只需重传当前数据分组即可。然而，这可能会产生重复分组。重复分组的根本困难在于接收方不知道它上次所发送的 ACK 或 NAK 是否被发送方正确地收到，也就无法事先知道接收到的分组是新的还是一次重传。 解决重复分组问题的一个简单方法（几乎现有的数据传输协议，包括 TCP，都采用了这种方法）是在数据分组中添加序列号（Sequence Number）：发送方给每个分组增加序列号。接收方只需要检查序列号即可确定收到的分组是重传的还是新的分组。

对于停等协议这种简单的情况，1 比特序列号就足够了，因为它可以让接收方知道发送方是否正在重传前一个发送分组或是一个新分组。下图给出了 rdt 2.1 发送方的 FSM，状态数是 rdt 2.0 的两倍，因为协议状态必须反映出发送方所发送的分组或接收方希望接收的分组的序号是 0 还是 1：

下图给出了 rdt 2.1 接收方 FSM 的状态，需判断分组是否是重复的：

其实不需要使用 ACK 和 NAK 两种确认消息，只使用一种确认消息就可以实现 rdt 2.1 的功能，这就是 rdt 2.2：无 NAK 消息协议。

接收方通过 ACK 告知最后一个被正确接收的分组序列号，这就需要在 ACK 确认消息中显示地加入被确认分组的序列号。发送方接收到对同一个分组的两个 ACK（即重复 ACK）后，就知道接收方没有正确接收到跟在被确认两次的分组后面的分组。

rdt 2.2 和 rdt 2.1 的细微变化在于，接收方此时必须包括又一个 ACK 报文所确认的分组序号，接收方此时必须检查接收到的 ACK 报文中被确认的分组序号。

现在假定除了比特受损外，底层信道还会丢包，假定发送方传输一个数据分组，该分组或者接收方返回对该分组的 ACK 发生了丢失，这样发送方都收不到应当到来的接收方的响应。协议现在必须处理另外两个问题：怎样检测丢包以及发生丢包后该做什么。通过使用检验和、序列号、ACK 分组和重传等，我们能够给出第二个问题的答案，为了解决第一个问题，还需要增加一种新的协议机制：发送方等待“合理”时间：

发送方不知道是一个数据分组丢失，还是一个 ACK 丢失，或者只是该分组或 ACK 过度延迟，在所有这些情况下，发送方的动作是同样的：重传。为了实现基于时间的重传机制，需要一个倒计数定时器（countdown timer）。下面给出了 rdt 3.0 发送方的 FSM，而接收方的 FSM 与 rdt 2.2 完全相同。

注意 rdt 3.0 发送方与 rdt 2.2 发送方有一个细微的差别，当发送方收到重复 ACK 时，rdt 3.0 什么都不做，直到定时器到时间后才会重传分组，而 rdt 2.2 的发送方收到重复 ACK 时会直接重传分组。 rdt 3.0 仍然是一个停等协议，因为分组序号在 0 和 1 之间交替，因此 rdt 3.0 有时被称为比特交替协议（alternating-bit protocol）。

rdt 3.0 已经是一个功能正确的协议，虽然采用停等协议使得该协议比较简单（只需要两个分组序列号），但性能很差，因为只有等收到了想要的 ACK，才会回到从上层接收数据的状态。如下面的例子中，假设端到端的传播延迟远大于数据分组的传输延迟，那么发送方对链路带宽的利用率是非常低的，即网络协议限制了物理资源的利用。

解决 rdt 3.0 性能问题的一个简单方法是：不使用停等协议，允许发送方在收到 ACK 之前发送多个分组，即采用流水线（pipelining）技术。流水线技术对可靠数据传输协议可带来如下影响：

所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。解决流水线的差错恢复有两种基本方法：回退 N 步（Go-Back-N, GBN）和选择重传（Selective Repeat, SR）。

在 GBN 协议中，允许发送方发送多个分组而不需等待确认，但它也受限于在流水线中未确认的分组不能超过某个最大允许数 N，N 常被称为窗口长度，GBN 协议也常被称为滑动窗口协议。下图显示了发送方看到的 GBN 协议的序号范围，定义基序号（send_base）为最早的未确认分组的序号，将下一个序号（nextseqnum）定义为最小的未使用序号，则可将序号范围分割成 4 段。 （1）在 [0, send_base - 1] 段内的序号对应于已经发送并被确认的分组。 （2）在 [send_base, nextseqnum - 1] 段内对应已经发送但未被确认的分组。 （3）[nextseqnum, base + N - 1] 段内的序号能用于要被发送的分组。 （4）大于等于 base + N 的序号是不能使用的，直到当前流水线中未被确认的分组（特别是序号为 send_base 的分组）已得到确认为止。

在实践中，一个分组的序号在分组首部的一个固定长度的字段中。如果分组序号字段的比特数是 k k k，则序列号的范围是 [ 0 , 2 k − 1 ] [0, 2^k-1] [0,2k−1]，所有涉及序号的运算必须使用模 2 k 2^k 2k 运算（即序号空间可被看作是一个长度为 2 k 2^k 2k 的环）。

GBN 发送方的扩展 FSM 如下所示，它必须响应三种类型的事件：

GBN 接收方的动作也很简单。如果一个序号为 n 的分组被正确接收到并且按序，则接收方为分组 n 发送一个 ACK(n)，表示到序号 n 的分组均已被正确接收。在所有其他情况下，接收方丢弃该分组（接收缓存实现简单），并为最近按序接收的分组重新发送 ACK。因此，虽然发送方必须维护窗口的上下边界以及 nextseqnum 在该窗口中的位置，但是接收方需要维护的唯一信息就是下一个按序接收的分组的序号。其扩展 FSM 如下所示：

在 GBN 协议中，单个分组的差错就能够引起 GBN 重传大量分组。顾名思义，选择重传（SR）协议通过让发送方仅重传那些它怀疑在接收方出错的分组而避免了不必要的重传。此时不仅发送方需要维护一个窗口，接收方也需要维护一个窗口。

发送方只重传那些没收到 ACK 的分组，因此需要为每个分组设置计时器。发送方需要处理的事件：

接收方对每个分组单独进行确认，需要设置缓存机制，缓存乱序到达的分组。接收方需要处理的事件：

序列号空间与窗口大小尺寸需要满足 N S + N R ≤ 2 k N_S+N_R\leq 2^k NS​+NR​≤2k 的关系，其中 N S N_S NS​ 表示发送方的窗口尺寸， N R N_R NR​ 表示接收方的窗口尺寸， k k k 表示分组头部代表序号的比特位数。